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Problem 

llie insuuclioiKil cnvironinciU created l)y siflf-piiciiig of mediated. tiuUerials requires continual 
evaluation of student progress, litis lias been previously accomplished by explicit or embedded tests items 
presented to students who have recorded dicir responses on pai^r answer sheets. In the Advanced 
Instructional System (AIS). these sheets are currently read by a ^^management terminaP' wluch ts connected 
to a central computer that records student responses and makes appropriate instructional prescrii)tions. The 
operation of the reading device with marked sense forms has resulted in a veryjiigh rejection rate ol U.rms, 
due to incorrect or unreadable inibrmation. Tlic problem is to achieve the desirable as|K^cts of diis system 
while eliminating the many problems resulting from the use of paper forn^s. 

Approach 

The approach investigated under work units 11:M)2.|7 and I121-0:.18 has been to develop an 
electronic equivalent to die paper forms used in the current system. In this system the student responds to 
questions on a small device called a "microterminal" which consists externally of a keyboard and several 
display devices. Internally, this device contains an entire, miniature, progiannnahlc computer, 'Ihis 
computer contains live diflerent testing strategics and '^)00 random test answer patterns, and is capable ol 
conducting an entire testing o^KMation without inteivention by any other compulcr. Provision is mude for 
presenting the resulting data to a cciural compiUer througli the AIS management terminal or to m:uiually 
remove data from the device. , 

In order to produce dtis product, it was necessar>' to develop several software and hardware tools 
with which lire microcomputer w:is sinudated, programmed, and constructed. The development tools are 
described in this re|X)rl along with the sequence of steps necessary lo reach the llnal product which is the 
microtcrminal. 

Results 

The microtern\inal works as designed and offers a higldy reliable alternative to the forms reader. The 
tools developed to build the microterminal arc available to support modincalion of this device or 
construction of families ol related devices. 

Conclusions 

The microterminal offers a solution to the problems of using the AIS management terminal and oflcrs 
many further possibilities for low-cost, reliable testing systems within the Air Force. 
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L INTRODUCTION 

The device described in this report is a prototype based upon experiences, both positive and negative, 
with the use of self.paced instructional materials in a military technical training classroom. The work was 
accomplished under two work units, 1 121'02-I7 and 1 12I-02-I8. Tliis report describes the evolution of a 
device and tlie technology which made it possible. It is the intent of this report to emphasize why the 
device has assumed its current characteristics, rather tlian to document Its internal engineering in detail 
since these internal details could change significantly due to the incredible rate of change of microcomputer 
technology. However, since a special type of engineering environment is necessary for the development of 
devices of this kind, several sections of the report outline the tools which had to be built in order to 
develop the prototype hardware and software. 

In order to accommodate a wider audience for this report, the product evolution is described in the 
first section, the development technology is described in the second section, and the resulting 
microterminal product in the tliird (Figure 1). 

^ 11. PRODUCT EVOLUTION 

The concept of self-paced instructional materials is not new to either the military or civilian 
conuiuinity. Such matericds have been in use for a number of years in the form of programmed instructional 
texts, student operated media devices, and in limited appHcations in the form of computer assisted 
presentations at computer terminals. Due to the historically high cost of developing and validating 
instructional materials in all of these forms, the additional cost of tlie presentation media has often forced 
the actual materials to be presented in the cheapest of these forms, which is usually the printed format. As 
a corollary of tliis growth of paper materials, the need to manage students with widely differing learning 
rates has placed additional burdens upon Ihe instructional staff. Because self-paced instruction 
accommodates these learning rates by altering student learning schedules, the group-paced, easy-to-manage 
conventional classroom has become the "learning center" with many different topics and techniques in use 
simultaneously by students proceeding at their own pace. 

The attempts to automate management of the instructional process have been far more limited than 
the application of self-paced instructional materials. The most operational of these attempts has been at 
Memphis Naval Air Station, Tennessee, where self-paced materials have been presented with printed 
materials and student performance monitored with self-administered tests scored and recorded by 
computer. The use of the computer has enabled tlie frequent use of evaluation without imposing heavy 
burdens upon the instructional staff. A similar approach was the design basis for instructional management 
of the Advanced Instructional System (AIS) being developed for the United States Air Force at Lowry Air 
Force Base, Colorado. 

The hardware and materials used in th; concept consist of a "management terminal" and differing 
test answer forms which are filled in by students as instructional materials are executed. The terminal 
houses a forms reader, printing device and interface minicomputer in a carrel designed for student 
self-operation. In tliis instructional scenario, the student is expected to study materials, take a self-test, and 
present the resulting answer fomi to the management terminal. The terminal reads the form, transmits the 
information to the AIS central computer, and presents the test results and an instructional prescription to 
the student on the terminal printer. The central computer records the student's performance, produces 
periodic progress reports to liis instructor, and retains information for instructional materials evaluation. 

While this may sound like ?n ideal situation for a teclinical training classroom, there have been 
problems in practice, centering around the paper fomis and reader. In order to provide response feedback 
to enhance leaming, special chemically treated forms are used which darken upon the application of a 
special chemical crayon, h is intended that these marks be read by the reader and provide data for materials 
evaluation and for evaluation of the student's perfomiance. In practice, the forms have proven difficult to 
read accurately, even when filled out properly by the students. This problem is accentuated by the fact tliat 
pencil marks used to identify the student and the test are spectrally different from the marks produced by 
the crayon. 
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Tills problem led to the belief thai an electronic approach (o ihe problem might resolve these physical 
dirncultles and possibly improve student perl'ormance by increasing the intensity of the student's 
interaction, Tlie solution tool^ the form of a device called a *^studont responden" In this device, a keyboard, 
several hexadecimal display elements (numbers 0..9 and letters A.,!') and a column of Individual di'jplny 
lamps were connected directly to a central computer through an interactive computer terminal. The device 
was driven by a program in Ihr central computer which read the keyboard and illuminated the appropriate 
displays, Tliis technique, while not satisfactory for a large number of responders» was adequate for 
experimental evaluation of the panel design and potential usefulness of the device. 

To use llie responder, the student would present his student I.D. number and his test booklet number 
to the device which would then tell him which items in the booklet to answer, and provide him with 
response feedback if appropriate. The program allowed several adaptive testing techniques and feedback 
modes. 

In order to determine whether this device could function effectively with existing instructional 
materials, a programmed instructional text which was currently being used in an inventory miinagement 
(supply) specialist course at Lowry was administered to a group of 50 students using the responder device, 
This text contains imbedded questions used to '^exercise'' the student and to determine whether he is 
mastering the material as he reads it. Wliile no significant gains were noted in [performance, the students 
were observed to cover the material about 30% faster on the average than students using chemically treated 
forms. In addition, 907o of the students favored the responder device over the chemical forms, suggesting 
that their acceptance of the device would pose no problem, All students questioned felt that the responder 
was easy to use and none required detailed personal instruction on its use. 

Our initial plan was to produce an adequate number of these devices to allow for testing a larger 
group of students; in fact a printed circuit for the device was developed, along with an interface controller, 
to interface sixteen of the responders through a single access point to the central system. It was our 
intention to use a PDP-11 family minicomputer to perform the connection to tlie AIS terminal network 
hardware, primarily because this was the type of minicomputer used in the existing management terminal, 
but also because its manufacturers had announced inexpensive versions of this computer based on large 
scale integration electronics. Due to rapid advances in the tecluiology of microprocessors, tliis approach was 
not followed. In tlie course of investigation of micmproa^ssors to determine whether one could be used 
instead of the more costly PDP-11 to perform the interface task, we discovered tlial a vastly different 
approach to the responder was technologically cost feasible. We will now describe the steps taken in the 
design of the next version of the responder which (because of its stand-alone abilities) was renamed the 
microterminah 

Throughout the development of the original responder, a major concern was that the student would 
become dependent upon tlie central computer for many hours of continuous, errorfrcc hardware a^J 
software operation, since he would be using tlie responder intermittently for most of the instructional day. 
Thus, if the computer failed even once during, Ibr example, a two-hour instructional module, the student 
would stand a good chance of being affected unless tlie central site were recording each minute interaction 
on disk; such an I/O usage at the central site would be detrimental if a large number of responders were 
employed. Also, the veiy infrequent requests encountered in individual responder usage would tie up more 
space at the central site than would be justified for the level of interaction which would be realized in a 
typical instructional situation. While this may seem paradoxical, it is typical of the instructional computer 
where peak to average processor requirements may vary by ratios larger than 1 ,000, 

The solution to this problem, and prelude to many otlier possibilities, was to incorporate a complete 
microcomputer into tlie responder. Due to the large production potential of these devices, manufacturers 
had already begun to discount their prices to the point where a complete processor could be assembled for 
several hundred dollars in parts. The future promised decreases in these prices by at least a factor of four, 
thus suggesting that production prices of no more than the parts cost of the prototype might be realizable. 
It appeared that such a device could be deployed immediately since it would be unaffected by the 
reliability of the central site for its normal operation. 

Tlie first step in the design of the stand-alone terminal was to determine its design limit, based not 
only upon its instructional icquirements, but also u^xMi the capabilities of existing technology to efficiently 
support these requirements. This is a delicate art of knowing where to draw the line between what is 
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wanted (wliicli mwMy 1ms in. liinlls) and what can be cosK-lTectlvoly achieved with the opllmuin 
loSlnallon or statc'l'-thcar. co.npunenls. in .1.0 time Ira.ue in which thi» worl< was comp^^^^^^^^^^ 
bcnctlted from the timely introduction of a scries oi' niicrocompnter componCHls by Motorola known as 
tlio M6S00 family of parts. Tills enabled the construction of tlie microprocessor wllliin a box wl\lch was 
nearly identical to the responder box in external dimensions. Tlie cxtcmai design of Oils box is indicated in 
Figures 1 and 2. 

The icmainder of tills report is divided into several sections dealing with the charailerlstics of the 
responder and each o. the tools which had to be developed to produce the prototype device. Because tlic 
microtern»ln:d is a self-contained comp.iter, it must be programmed to perform tlic taslcs assodated with 
the identillcation of Uie student and tlic administration of tlie test or Instructional material. This program 
had to be developed for h computer which did not yet exist; i.e.. the one to be contained in the tcrmliial. 
This "taruet" comDUter would have "'^ facilities ior tlie development of software since its nornial functlori 
would be U. scoJe'a test, so a niore capable computer liad to be obtained or built on whiclj lie so f ware 
could be developed and tested. It is I'lcommended tint readers not interested in the details ot this 
development process turn to Section IV. 

III. TMI-: MICROCOMPUri-R SOIT^ARE/IIARDWARE DEVULOPMUNT SYSTEM 

Tlie PIMI'L Progiramming Language and Compiler 

■'.'l.e snecific microprocessor to be used in the microterminal was chosen for a nui'.ibcr of reasons 
relating to u "t. msc of use, ease of programming, and Its ability to be constructed into a small physical 
amtainer At the initiation of this pliase of the project, the Motorola M680O microprocessor was the best 
choice considering all aspects of tlie design problem. Its weal<est feature at the time, however, was that very 
little software existed to assist in the production of M6800 pmgranis. Of tlie available software, all was 
incompatible with the development comp.iters avaUable to support the project. For this reason, we 
undertoolc tlie development of In-house software to aid In the programming of tlie microcomputer we were 
planning to build. Because of the badcground of tlie people involved In the project, it was decided tliat a 
large portion if the manpower Involved would be spent In building good software tools, followed by a 
relatively shor. usage of these tools to program the prototype. Our reasoning was tliat the final product 
time would be 'jbout the same regardless of how much time was Invested In the tools. By emphasizing tools 
rather than end product, we would be much better prepared for future modifications and developments m 
the microterminal or in related systems requiring a microprocessor for Implementation. 

A rather uniquv assembly language was developed, because tlie design constraints of size and cost 
•mandated a highly compact program, wliile future needs suggested modlfiabillty and versatUity as 
Important factors. The assembler program .used to translate this language Into M6800 machine code was 
written to run on the AIS CDC CYBER 73 central site computer, thus Tial<ingit available to any Air Force 
installation having AIS terminals. The assembler is written in the PASCAL language which is excellently 
implemented on the central site computer. Because PASCAL is an ideal language for the construction of 
wmpllers and assemblers, the actual manpower required to write this program was about eiglit man-weeks.- 
Tlie acronym PIMPL stands for 

P rogrammable 
I nstructiunal 
M icroprocessor 
P rogramming 
L anguage 

A priniar:/ advantpge In this implementation is that PIMPL programs may be edited using tlie powerful AIS 
program editor, submitted to the assembler for translation in a few seconds, and tlie resultant program 
transferred to the M5800 development processor for esting in a matter of minutes. Thus once these tools 
were available, the complete responder program was written in a matter of days and can be modified now in 
a matter of minutes. 

The notion of an algorithmically formatted assembly language is attributable to Nil<laus Wirth, who 
designed the assembly language PL360 for the IBM 3t.O series of full size computers. Previous experience 
with this language suggested that such an approach might be quite suitable for the programming of 
microcomputers, the language also bears some similarity in purpose to the PL/M language 
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implemented for the Intel 8080 microcomputers, although it was intended that PIMPL would relate closely 
to the capabiUties and limitations of the M6800 microprocessor. By including such language structures as 
procedures, IF-THEN-ELSE statements, and WHILE-DO statements such as found in high level 
programming languages, the flow of the resulting PIMPL program is much more transparent to the 
programmer. We feel that this significantly enhances the readabiUty of the resulting program as well as 
reducing the number of logic errors in the program. Detailed statements, however, allow the efficiency 
which only most assemblers achieve and enable the resulting program to be small, thus reducing the cost, 
size, and power requirements of the finished product. 

The asseihbler can be characterized as a top-down recursive descent translator, and appears to 
translate PIMPL at a rate of about 130 to 180 lines per second on the CYBER 73 computer. It requires 
approximately 40,000 octal words of machine storage for execution and is currently merged with the 
M6800 simulator program (described in the next section). This merger allows the immediate translation and 
simulation of PIMPL programs. 

The PIMPL language allows the user to describe the storage of the target microcomputer with 
descriptive names of variables and constants used in the program. It uses attributes of these descriptions to 
check the syntax of the program as it is being compiled, and the feasibility of its execution in the target 
computer. For example, it will not allow storage allocated in a'"read only" type of memory to be used in 
such a way that its value would be assumedly changed as the program runs. The bulk of executable 
statements are the assignment or function type, such as 

A^5+B AND BITMASK or 
CALL TIMER 

These are translated directly into machine code for the M6800 microprocessor. When an iterative condition 
is needed to express an idea requiring repeated test or looping, a statement such as 

WHILE A<5 DO 

BEGIN LIGHTS -LIGHT; A^A+1 END: 
might be used to express the concept. If the user wishes to make a conditional execution he might use a 
form such as 

IF A=0 THEN B^5 ELSE CALL SOMEFUNCTION or 

IF A<B THEN BEGIN A^B;B<K) END . 

Statements may be grouped together into procedures such as 

SOMEFUNCTION: PROCEDURE; 
AM;B^5; 
WHILE A<B DO 
BEGIN A^A+2; B^B+1 END; 
RETURN; 

which may be called by statements such as 
CALL SOMEFUNCTION; 

In the event that an enor is detected in the program by the compiler, it produces an error message of the 
form: 

X^ X+1 CALL TIMER; 
_ ^ SEMICOLON EXPECTFD 

notifying the programmer where the error was detected, and, if possible, what caused the error. In this way 
the time consumed correcting typographical or feasibility errors is minimized. 

By maintaining a policy of only implementing capabilities which are directly supported by the M6800 
microprocessor, we kept the compiler small, fast, and easy to write and debug. We feel that the resulting 
small size of the responder program in relation to what it does verifies the correctness of this approach for 
the M6800. A section of the responder program is included in Figure 3 to demonstrate how well the 
language can describe the flow of the microprogram when properiy used. The example was the first 
program written by one of the authors, who is not a professional programmer. Without being familiar with 
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[THIS -O'jTI'i, -ViN'-AT-^ f-i\rjl0'^ OF A ^^CO M CLOC<S P^^QM 

DUL millt3lCo\".^ •••-a •> j.^fi^-: :MT-:^''^ijr^T ':Lc:<.t 

IF niL'\V>-) THd^J 0£.L^iY!=OEL'i^-i:[^OP CfiLLEO C£LAY1 
M SC'"J!JNT t^^'SD^ijfiT -1 : [FO^. 'v3FTW;'-'£ CLOC'^'] 
If MSCOilNf:: TM^N 

P-GiN t-^LOCK 30Ni ONLY iVI-v 1 0 T ?KC1 

a;=:M;: ^SCOJNT:^^: C-^TSfT i T H ScC CT£^1 
T£N THCC'jfIT : - T :kTHCO'JN T-1 : 

IF Tu'TFLAGo, THf.M 
IF Tr".NTHCO'J"!T = u T'^'^N 

S::cor-uis; = :£co nds + i ; a : = cc nos; 
*ir a=oO nffj 
^ > G I M 

:rn: 
a : =Hi NIJTE3 : 
IP /\ = 6n THEN 

n:GiN 

"^IMmT'"5:^ = 0* HOURS : =M3UP3+It 
r M n : 

£M.K 

a:=;^a; f•^».-SE^s i-^oa flag in -^iai 

Figure s. Sample of PIMPL programming code. 



anything about the program, you could probably'delermine what this routine does from the information in 
the listing. This desirable trait is called "self-documentation" and is not commonly found in assembly 
language programs. 

When the compiler has finished translating die program into M6800 machine instructions, it records 
these instructions in the disk system of the CYBER computer for later transfer to the microcomputer at the 
request of the programmer. It then prints a readable listing of what the contents of the target computer will 
be, so that this information may be used while debugging the program or for purposes of ordering read only 
memory circuits if desired. The microcomputer can also store this information in field programmable read 
only memories if desired. Normally, at this point, control will be transferred to the simulator program for 
trial execution. 

Debugging the Initial Program - Software Simulation 

When a PIMPL program has been successfully compiled into machine language, it may still contain 
logic error3 which would not be revealed until it begins to execute. At the normal time of execution, 
however, the program will exist in a miniature, minimally configured box designed to perform a specific 
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Umited function, which does not include the development and debugging of computer programs In order 
to debug the program, all of the features of large scale, high-speed computers v/ould prove benefiaal. To 
obtain ^ese benefits, the microcomputer to be built is "simulated" by a computer program nrnmng on the 
AIS CYBER computer. This simulator program can perform monitoring and checking tasks which would be 
infeasible to build into hardware devices specially designed to debug microprograms. 

In order to minimize the user tin.e required by the simulation step, the simulator program should 
contain very proUfic information which-is not obtainable in the high-speed execution environment of the 
actual hardware, but which is useful in determining whether the program is operatmg correctly. The 
simulator written for this project includes the following features: 

1. control of maximum simulation run time 

2. full display of microprocessing unit (MPU) internal registers 

3. assignment to program counter 

4. simulation traces initiated by accessing within a range of addresses 

5. simulation traces initiated by MPU clock tlEies 

6. simulation traces controlled by opcodes executed 

7. timed interrupts to write or alter data in memory 

8. timed external MPU hardware interrupts 

9. timed controls for partial memory and variable listings during simulation. 

During simulation, a trace is printed for each machine instruction. Each Une of trace Usts the Une 
number, program counter, index register, stack pointer, A register, B register, six condition code flags, 
cumulative MPU clock time, and new program counter. By correlating the trace Usting with the program 
listing, it is quickly possible to analyze and debug logical errors in the source code. 

Each simulation feature is controUed by a one-line data card attached at the end of the PIMPL source 
program. The first number of the line selects the type of simulation command (i.e., one of the features 
Usted above). The remaining one to four numbers give the parameters of that command, such as designating 
at what time the interrupt should occur, or identifying at what program address the simulation hsting 
should begin. Following is an explanation of each type of control card. 

Simulation Run Time: command designator number 0 foUowed by one number for the maximum 
desired run time, expressed in microseconds. For example, a simulation data card (i.e., one hne of data 
attached to 'hi- end of the PIMPL program) with 0 2000 will permit the simulation to run for 2,000 
cumulative M:'i I (microprocessing unit) microseconds before terminating the simulation run. 

Initialization of Program Counter: command designator number 1 foUowed by one number for the 
decimal value of the new desired program counter. If this command is not used, the program counter is 
estabUshed by the normal hardware convention of using the microprocessor startup vector which points to 
the starting address of the program. 

Simulation Trace by Address: command designator number 2 foUowed by two numbers for the 
beginning and ending program counter addresses for tracing and Usting the simulation. Any program rode 
executed between these two addresses wUl be shown in the simulation trace. For example, a control data 
line with 2 64000 64200 wUl provide a simulation trace whenever that part of the program bei^^^xecuted 
is between program addresses 64,000 and 64,200. • ' 

Simulation Trace by Qock: command designator number 3 foUowed by two numbers -for the 
beginning and ending cumulative MPU time for which the simulation trace should be Usted. For instance, a 
data Une with 3 2000 5000 would aUow a simulation trace to be Usted when the MPU is running between 
2,000 and 5,000 microseconds of the total simulated real-time run. 

Simulation Trace by Opcode: command designator number 4 foUowed by one number for the 
opcode' Whenever the microprocessor instruction with that opcode is executed, a one-Une simulation trace 
is provided. As with aU the simulation commands, more than one may be used by having muUiple data bnes 
attached at the end of the PIMPL program deck. 

■ 17 
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TuT.ed liiterrupts: command designator number 6 followed by four numbers, There are four types of 
interrupts used, a hardware interrupt of the MPU, a nonmaskable hard\yare interrupt of the MPU, an 
interrupt that will write or alter a byte of data in memory, and an interrupt that will list a designated page 
of memory at a predetermined time. This last type is transparent to the actual simulated program, but 
provides the user with a current list of memory and stored source program variables. Each of these 
interrupts is designated by the fourth parameter number, numbered 0 to 3. 

The fLtst of the four numbers designates at what time the interrupt is to occur, expressed in 
microsecond.'^ accumulated from the start of the run. The second number tells the memory address location, 
The third number is the data that is to be written into the memory address of the second number when the 
fourth number is a 2, which specifies a write into rxjemory. And the fourth number, 0 to 3 in value, 
designates the type of interrupt. 

An example of a hardware interrupt would be 6 2000 0 0 0. Here the first number, 6, indicates an 
interrupt. The number 2,000 indicates the interrupt is to occur at a time of 2,000 microseconds into the 
simulation. The next two zeros are ignored while the last 0 indicates this is to be a hardware interrupt as 
opposed to a nonmaskable, write memory, or page dump of memory interrupt. 

An example of a nonmaskable interrupt would be the same except for the last number, 6 2000 0 0 1. 
Here the 1 distinguishes a nonmaskable interrupt from a normal interrupt. 

An example of writing data into memory at a given time would be 6 2000 65000 77 2. This is 
interrupted by the simulator as, "at a cumulative MPU time of 2,000 microseconds write into memory 
location 65,000 the value 77." 

The fourth type of intemipt is the page dump. Here 6 2000 255 0 3 is interrupted by the simulator 
to mean, "at a cumulative MPU run time of 2,000 microseconds, print the contents of the 256th page 
(pages numbered from zero) of memory and then continue with the simulation." This is a transparent 
interrupt with (he result that all inemoiy locations between hexadecimal FFOO.and FFFF will be printed at 
that point of time in the simulation listiiig. 

As mentioned, each, type of command card may be used many times. As an example, suppose a 
program is quite extensive and involves a large amount of simulation time. Simulation traces controlled by 
address, time, or opcode may be discriminately fumed on and off, listing only those portions of the 
simulation the author is concerned with. A simulation representing a microprocessor controlled sequence of 
events or interactions with the external world could conceivably take several real-time seconds or minutes. 
The program trace can easily be configured to follow only those interactions the author is presently 
concemed with. Software delays and wait loops may be skipped and counters may be changed-jumping to 
new segments of executable code. Interrupts may be interjected to simulate external interactions with 
switches, controls and signals. 

Upon completion of the simulation, a listing is provided of all declared random access memory 
(RAM), read only memory (ROM) and I/O (input/output) ports. This is given by page number, byte 
number, decimal and hexadecimal value, and designates whether it is RAM, ROM, or an I/O port, and 
loaded or unused space. This type of listing is useful for a number of reasons. It shows the amount of object 
code generated by the assembly, the final value of all the program variables stored in RAM, the location in 
memory of specific procedures, the actual object code generated by the assembler, an overall mapping of 
memory and I/O ports which is useful for correlation with actual hardware addressing schemes, and a means 
of verifying object code placed in ROMs or PROMs (programmable ROMs). 

Hardware Development System 

Once a good language, assembler and simulator have been established, the final component necessary 
for a complete microcomputer aevelopment system is a hardware emulator (Figure 4). It should be a 
working, self-contained mica^omputer that not only duplicates the microcomputer (proposed in the final 
hardware design) but also indisdes many features to facilitate program development and debugging. 

It may initially, take longer to develop such a system, but once completed it will pay for itself many 
times in time saved during the microcomputer development process. The capability to "look inside" the 
microcomputing process, halt and display information, read or write memory data, and continue running 
becomes an invaluable aid. With this tool, if properly designed and used, development efficiency increases 
significantly. 

18 
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Tlic basic concept is lo write and simulate your microprocessor application program until it 
approxiniat'eV the tinal product, 1*licn the assembled program is loaded into the hardware system. The 
iiardware emulates the proposed hardware design and executes the object code as it would be done with the 
final version. 

At this point it is possible to test the ■micro-controlled hardware. If carefully designed, all is near 
completion. However, this is when the hardware may reveal some logic errors in the software or when the 
author's notions of the system design and implementation in his program fail to meet the actual physical 
requirements. However, using the hardware development system, with its many front panel controls, one 
can quickly and easily remove any remaining hugs from a progrrjn. 

Tlie development hardware includes three integrated circuit boards, a front panel with hexadecimal 
displays and switches, power supplies and a Plexiglas cover. The three large boards are functionally divided 
into a central processor board, memory board, and control panel board (Figure 5). 

The central processor boa.d includes the Motorola M6800 microprocessor, a crystal-controlled, one 
microsecond system clock, a one millisecond clock derived from tliis clock, a bootstrap loader, tluee 
peripheral interface adapters (PIAs), input and output buffering of the 16 bit address bus and 8 bit data 
bus, 768 bytes of random access memory (RAM) with a read/wrte protect switch, and a resident 
programmable read-only memory (PROM) programmer and socket for 4k and 8k Intel ultra-violet erasable 
PROMs. 

Tlie memory board has 3k bytes of random ;iccess memory arranged in three rows. Ik by 8 bits per 
row. with room on the board for another row. There is sufficient buffering of bus and data lines, and 
decoding logic for an additional 4k bytes of memory to be added by connecting another board. The 
memory board has a protect switch that disables tlic write function of the memory, thus making it into a 
psuedo ROM. 

The third board is the control board. As compared to the MPU and memory boards, wliich are 
inherently clear as to the functions they perform, the control board should contain all the "bells and 
whistles" and development aids necessary to tacilitate development and debugging of hardware and 
software. Initially, it is not always clear what these features are and which are best to have, but the 
necessity for a powerful and flexible control bo:;rd with panel will manifest itself during the development 
process. 

With this brief overview of the developnv.ot hardware, a chronological description of adevelopment 
process will show how the system is used, sonit its authoring and debugging features, and the power and 
efficiency with which one person can develop an elaborate, microcontrolled, interactive, hardware/software 
system. 

Tlic development cycle is a continuous process of authoring software, editing, assembling, simulating, 
and emulating in hardware, with implied debugging throughout. Tliis sequence is repeated in one form or 
another. until a final product is produced. A program is interactively written m PIMPL at an AIS terminal. 
When assembled,- the program is stored in the disk system for transfer to the hardware emulator. To serially 
transfer the object code, an AIS CAMIL (Computer Assisted/Managed Instructional Language) program 
called TRANSPORT is run at the AIS terminal. 

TRANSPORT will automatically scan the PIMPL program data for declared ROM starting at address 
0000 and scanning to the full addressing width of 65,.S35. For each contiguous segment of code, normally 
divided into 256 byte pages, TRANSPO^RT will serially output the high and low byte starting address and 
tlie number of bytes to be transmitted, followed by the actual object code data. Tlie CAMIL language has a 
unique feature incorporated into its compiler and interface software for outputting data through an 
external output jack at the rear of the AIS terminal. The CAMIL software command, when executed, 
serially outputs a 20 bit word, with a timing pu.ie for each bit, and a sync signal for the end of each 
transmitted word. The output data rate is sixty, 20 bit words per second with the last 8 bits of each word 
serving as the actual data byte. Thus, In one minute about 3,600 words of PIMPL program may be 
transferred to the hardware emulator. 

While TRANSPORT is running, the AIS terminal displays each page number and page length being 
sent. When the serial output of all PIMPL object code is complete, a message will appear at the terminal's 
screen staling that the output operation is finished. The operator then sets the memory protect switch 
located on the memory board of the hardware enuilator. This has the effect of making the random access 
memory ;'rray of the hardware emulator appear as if it were now read only memory and nondestructive. 
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Figure 5, Hardware development system. 
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In order to receive data from the AIS computer, the hardware emulator uses a program called a 
bootstrap loader. One of the three PlAs on the central processing board is used for this interface. Coaxial 
lines are used between the terminal and emulator with SN7545I line drivers and SN7414 Schmitt receivers. 
Because this technique is good for frequencies to 20 MHz over distances of 100 feet, no parity is sent and 
no error detection or correction is used. As it turns out, several dozen transfers, with 24 thousand bits per 
transfer, failed to produce one error during emulation. 

The bootstrap loader, once loaded and turned on, causes the emulator MPU to sit in a wait mode 
until interrupted by an extemal interrupt from the PIA. Asthe data is serially received at the emulator, the 
receipt of each fnll word causes a serial to parallel 8 bit shift into the PIA and an MPU interrupt. The MPU 
stores the byte in the next appropriate, sequential location of memory and then waits for another byte. 
Initially, at the beginning of each transfer the loader expects the hi^ and low address and length to be sent, 
followed by the data. The MPU is fast enough to service each interrupt and byte sent to it through the PIA, 
and yet stay well ahead of the data transfer rates. 

The bootstrap loader may be hand toggled into RAM by using the address and data switches on the 
front control panel, or a ROM version residing on the MPU board may be used after its starting vector is 
toggled in at the highest two addresses of memory. 

The entire process of recompiling a large PIMPL program, transferring it by using TRANSPORT and 
the bootstrap loader, and running a new version of the program in the emulator, takes on the average 
between three and five minutes. A three to five minute tum-around time becomes an invaluable 
development aid. The programmer's output increases manyfold and complex microcomputerized systems 
are not only realizable, but with minimal time and effort. 

Features and controls of the hardware development terminal or emulator that facilitate user 
development of software and hardware include: 

1. complete microcomputer emulation 

2. resident bootstrap loader for swapping programs from the CDC Cyber computer 

3. psuedo ROM via RAM read/write protect switch 

4. resev, halt and run switches 

5. single cycle with hexadecimal display for address and data bus 

6. software controlled breakpoints with display of all intemal MPU registers ~ 

7. address controlled breakpoints with display of all intemal MPU registers 

8. breakpoint continue/run switch from trap 

9. 16 address and 8 data switches with read/load control 

1 0. peripheral interface adapters for emulation of prototype; hardware 

1 1, automatic PROM programmer with socket 

Tlie thought process by which an author debugs his program is unique unto liimself. The intent of the 
type of controls provided, is to give him enough flexibility and capability to perform any type of logical 
debugging he desires. Normally, an assembled program listing (showing the address of each line of program 
code) is used in conjunction with the emulator. Tlie program logic flow is followed on the Hsting while 
emulating. When something goes astray, the control panel switches and display "windows'' enable the 
designer to "look inside" his program to learn what is specifically happening during execution. 

After a program is first loaded into the emulator by the bootstrap, the RESET switch is pressed, 
followed by the RUN switch. Then while running, the MPU may be halted at any time by flipping the RUN 
switch to the HALT position. Once halted, control of the bus is given to the front control panel. The 
address display (4 hexadecimal digits) will show the last address on the address bus prior to halting the 
MPU. Likewise, the data display (2 hexadecimal di^ts) will display the last data to appear on the data bus 
' prior to halting. If the MPU is not halted, the address ard data are still displayed, but change. at the 
processing speed of the MPU, causing tlie display to appear as a blur to the human eye. 

When in the halt mode, each successive depression of the single-cycle switch will permit the MPU to 
execute the next program command. This action also updates the address and data displays. With this 
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Icaturc. the autlior may "walk" tlirough liis program one step at a time while comparing the address and 
data displayed with the logic of his program listing. 

if additional-information is necessary for debugging, the internal registers and condition codes of the 
MPU may be displayed on the front panel. Display of this information is initiated in two ways. Tl.e author 
may insert the PIMPL command SWl (software interrupt) in liis program at the point the display oJ 
information is required or he may toggle the appropriate program address on the front panel and enable the 
NMI (nonmaskable interrupt) switch (also on the front panel). 

Both the SWl and NMI cause the MPU to display the value of its registers at 'he point in the program 
where the command is encountered, and then halt the MPU and emulation process. Information displayed 
includes the program counter, stack pointer, index register, A register, B register, and condition code flags 
for carry, overflow, zero, negative, interrupt, and half carry. TTiis information may be correlated with the 
program listing for possible bugs. VVl.en complete, the MPU may be restarted by hitting the SWl/NMl 
continue switch on the front panel, 

Tliis information is normally not available to designers because of no access provisions on the MPU 
integrated circuit. However, the SWi/NMl feature of the emulator causes the MPU to jump into a "priority 
display and halt" mode. Wlien a software or nonmaskable hardware interrupt is encountered by the MPU, it 
places its internal contents in the memory stack while processing the interrupt. The emulator copies the 
information stored in the stack, displays it on the front panel in a hexadecimal format, restores the MPU 
from the stack, and then halts the MPU. Tliis entire process is transparent to the program runmng m the 
hardware emulator, but provides a powerful aid to the developer. 

When the hardware and software development process using the simulator and emulator is complete, 
the designer should have a smoothly running system that is a version of the machine he eventually hopes to 
buUd All the logic design for the microprocessing unit, input/output interface, extemal signals and 
software should be complete. All that remains for the designer is to reconfigure his hardware as a 
stand-alone system (i.e., no longer using the emulator, but instead, the actuid integrated circuits) and to 
transform his assembled software code from the psuedo read only memory of the memory board to ROM 
orPi^OMs. 

Since the emulator served as a hardware prototype, the reconfiguration to a stand-alone 
microcomputcrized system from the emulator is a straiglit forward process. The electronic schematic 
diagrams and circuits used during emulation arc the same for the fin?! product. ^ 

Programming PROMs may be done quickly and automatically using the hardware development 
tenninal Tlie assembled code already resides in the p^..icdo ROM area of the memory board. The bootstrap 
loader in conjunction with the program, TRANSPORT, loads the PROM programmer program from the 
AIS computer into the hardware development terminal at a predesignated and reseived part of memory. 

TIic program's listing of the memory map; provided at the end of each PIMPL assembly, is used to 
divide the object code into sequential sections of 512 or 1024 bytes of code. Tliese sections provide the 
code for each PROM to be programmed. 

To program a PROM, an ultraviolet erasable 4k or 8k PROM (Intel's 2704 or 2708) is placed in the 
socket located on the MPU board. Tlie 16 bit starting address (high and low order byte) for the section of 
code to be programmed is toggled into memory, at location 0000 and 0001 using the front panel controls. 
The PROM programmer program is RESET and RUN. A smaU red liglit next to the PROM socket will be lit 
during the programming cycle. VVlien the cycle is complete, approximately 2 1/2 minutes for a 4k PROM, 
the liglit turns off, the PROM may be removed, and the ne.xt PROM may be programmed using the same 
process. 

it becomes a simple process to reprograin the PROMs fur a new version of software. To do this, Intel 
PROMs are exposed one inch from an ultraviolet light source for 20 to 30 minutes. This erases the old bit 
pattern stored in the PROM, and readies the PROMs for a new programming cycle. 

24 ' ' 
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IV. Di'SCkirnoN oKTiii: studiiNT microti:rm.nal 



The lolloving section will give a description of tlic fmiil version of the student rnicroterminiil 
exphiining its physical hiyout. resident controlling program and microcomputer electronics. 

Refer to Figure ] ku an illustration of. the inierotermirial. The boy shown measures approximately 10 
by 5 by 3 inches, yet cofitains the entire electronic; and memory for a stand-alone computer tluit has five 
testing strategies and ^00 multiple-choice answer patterns. 

Messages used in a dialog with the student are conveyed by means of lighting a small red light 
adjacent to each printed message on the front panel. The current version has fourteen small liglits for 
messages. Six of these are used for messages with tlie student while administering a test, two more arc for 
yes/no feedback, four are used when extracting data collected while in the instructor mode, and the last 
two liglits are unused. It is possible to add more lights or to have more tnaii one light on at a time, if 
niultiple messages are desired simultaneously. 

The display located in the middle has four light emitting diode (LED), hcxiidecimal displays which 
display the numbers between 0 and ^ and the characters A through E for multiple-choice response 
feedback. 1 aiuer numbers, such as a nine digit social security number, are displayed by stepping the 
nutnbers acfi»ss the four-digit display from right to left as they are entered. 

The keyboard's sixteen keys include the numbers 0 through CLEAR, SEND, and four blanks, Tlr: 
keys numbered between I and 5 also have the letters A througli E printed on them for multiple-choicj 
responses. Several differem riumufact ured keyboards were tested until one was lound which had a positive 
uictile feci and whose key lmos could be altered for messages appropriate to our testing scenario. 

Tlie prototype box is made from one-eighth inch and three-sixteenth inch white opaque Plexiglas. 
This has proven to be an easy material to work with and has withstood a lot of rough handhng. 

The PIMPL progrLini that controls the box resides in six 512 by 8 bit, ultra-violet erasable PROMs, 
tour of which are for the program and two more for test answer patterns. If the testing pattern is ever 
compromised, the two PROMs holding the answer pattern may be easily exchanged for two new ones 
without alTecling or altering the other four PROMs. 

Tlu* PIMI*L program is sequentially arranged in die order of declarations, answer arrays, procedures, 
program body, and iniiiali/aiion of hardware vector pv^inte^s. Ljogieally the program is executed by first 
initiali/ing variables, then by receiving the user\s soei.'tl security number and test booklet number, followed 
by administration of the icsi . and concluding with the calculation-and display of the final test score. 

Ilie type of test suategy to be used, the answer pattern for ;hc lest administered and the length of 
the lest aie all derived innu ilie live digit test booklet number that the student enters. 

Extensive software w:ls develojxjd to prevent the student from entering erroneous data, such as a 
nonexisteril or invalid booklet inimber, and to prevail him from accessing proprietary information. In 
cveiy case, the microlerminal box has not been difficult to use by students attempting to use it for the first 
time. The lights and messages and natural progression through a testing si rategy, seem to be well luinuui 
factored and not confusing to new users. 

Because of ilie nature of the Pl.MPL language jnd the extensive use of procedures in developing the 
microteiminal j)rogram. the actual amount of code generated s quite compact. All together, 29 separate 
protvdures are used, with nestiiui of called pioccdnres several levels deep. Tliis approach makes software 
development that controls ami u pl^es hardware much easier and more logical to the develoixr. The actual 
body of the program is lelairvcly ,h.»ri cuinpared to the rest of the program listing, hut it visibly eon tains 
the entire outline and slructiirc «4 -'le i!ram. 

When tasks are retjaircu, such a^ receiving 9 keyed inputs from the student for his social security 
number followed by a SE.ND key. a procedure called A(T'I-:PT is simply called with the variable. LENCiTII, 
initialized to nine prior to the call. .'XCCIilH' (in turn) uses (Jtlier procedures, which in turn call other 
segments i>f code. In this way. code is used very elTiciently. 

it is important to note thai when designing a hardv/are/sofl ware, system, simple trade-off studies are 
necessar\' to deicrmiue if :i control signal, electrical pulse or some function is more ctTieiently implemented 
in software or in hardware. With the current availability of large read only memories at low prices combined 
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with tlic P..WC., siK-cd and ncxibility of the microprocessor it becomes very cost -oiToctivc to implcnent as 
mucii o|- tl.c control iK.rdware in software (also retcrred to as firmware) as possible. 

Tins approach was used in the* design of the microtcrminal. A g(iod example of this is in how tlte 
keybo .d is 1 '.tdled. Scanning of the keyboard for depressed keys, enco ing of the ^^y^.^^f^-'-^/.^^*^^ 
during dcpi.sslon, and key lockout if more than one key is pressed at the same time is all handled by the 
microprocessor unci firmware. 

I.or the prototype microterminal. five testing strategies were implemented and reside in tlie "box " 
The first strategy is merely a linear progression through a test, with n" correct response tcedback. T c 
e ond tratcg>' is a linear progression with yes/no response feedback. The third strategy is s>>" ar o t ^ 
second except that when a test item is missed the student must remain at that item until he get it correct 
The fourth strategy is the same as Uie third except that at the end of the test, the stuaent loops back 
around and continues taking each questiiin he missed, until he has answered tliem correctly. 

The llfth strategy implements a form of adaptive testing called fiexilevel. 
testing is to detemiine a .student's comprehension level of the subject matter by using an ^'S""''"" J^' 
as few questions as necessary during the test, but which maintains as higli a correlation as possible to the 
test score that would have been derived had all the test questions been asked. 

In a fiexilevel adaptive test, the questions are ranked from the first to the last item according lo 
increasing degrees of difficulty. In the strategy implemented, the first question administered is the middle 
uS of file test. Each successive question asked is based on whether the preceding question was 
aSr d correctly or incorrectly, a higher numbered question for correct and a lower numbered quest.m 
Jc" incorrect. In tltis manner the test continues until the student finishes at the last question or he fir 
numbeJed question of the test. The fifih strategy uses this technique, using any variable length test and 
always starting with the numerically middle question. 

' At the present time, a hardware interface is being developed which, will enable the microterminal to 
swap its gathered student test data into the central computer-managed system at the completion of a test. 

For tiic present time, until the central interface is complete, information may be manually retrieved 
from the terniinal while in an instructor mode. To log on as an instructor a special sequence ol keys is 
pressed. Once fiiis is done a red light will appear next to the message that says 'Instructor Mode. 

To retrieve information while in instructor mode, a key a-rresponding to the same number of a light 
with appropriate message is depressed. For instance, if when in instructor mode a 1 is depressed, the nine 
S od il security number miy be stepped across the display. A 2 will display the booklet number. A 4 
wil d splay the student's score, wltile a 5 will display the elapsed time taken dunng the test as expressed in 
K un S niinutes. Key 6 depressed (used in conjunction with the SEND key) wdl display each missed 
s^i n a d all the incorrect'responses given for that question. For each of these instructor functions 
appropriate lights and messages are used to facilitate the retrieval process. The microterminal ,s reset for a 
new student by depressing the blank key under the CLEAR key while in tne instructor mode. 

It was mentioned previously that the elapsed time during a test was measured. This capability is 
performed by an interesting combination of hardware and software. Tlie microprocessor mcs a one 
Eo^cond crystal-controlled system clock. From this frequency, a millisecond clock is denved in 
hardware by us^ig three successive decade counter.. This ntillisecond clock interrupts the microprocesso 
a h one-thousand of a second. Slower clock periods are derived from this interrupt. Each i.i^^errup 
increments a software millisecond counter which in turn affects one-tenth second, second, runute and hour 
software variable clocks. 

Not only is this timing mechanism used for measuring test durations, but it serves njany other 
purposes, such as for short time delays in key debounce routines, strobe pulses for latching da la o the 
mic?otermin:il displays, and for timed pauses when displaying messages such as the yes/no test item 
feedback. 

The microterminal hardware ciinsists of a Motiirola M6800 microprocessing unit a 128 x 8 bit 
random-access memory chip, six 40% bit programmable read only memories, a 1 megahertz clock one 
peripheral interface adapter, fourteen discrete liglit emitting diodes, four hexadecima displays, a ixteen 
key keyboard, and a few discrete transistor-transistor locic (TTL) intefrat.d circuns. Except for the 
keyboard all these irts fit on a 4.5- by 6.0-inch board that mounts against the underside of the top panel 
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of the microtcrnunid box. By maintaining a compatible family of microcomputer integrated circuits, such 
as the Motorohi 6800 family, and by performing many of the hardware control functions in software the 
total parts count was kept low thus enabling the building of the entire microcomputer with appropriate 
student interactive displays on one small board. Refer to Figure 6 for a functional block diagram of the 
complete niicrotcrniinal. 



V. CONCLUSION 

The stand-alone testing terminal, described in tliis report, is the tip of an iceberg which could greatly 
change the numncr in which testing is performed in the armed services. Specific systems may be relatively 
easily developed which emphasize testing technique, test item security, learning during testing, or 
automated entry of test results for item or response iuialysis by a larger system. The greatest difficulty will 
be obtaining assembled devices such as these in small quantity without losing the low-cost potential of the 
imbedded microcomputer, and in attacliing families of these devices to current inappropriately designed 
central systems. If solutions to these problems can be found, the full potential of reliable, automated, 
scH-paccd learning centers may be realized. 
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